1. Technical Field
The present invention relates in general to designing, simulating and configuring digital devices, modules and systems, and in particular, to computer-aided design, simulation, and configuration of digital devices, modules and systems described by a hardware description language (HDL) model.
2. Description of the Related Art
In a typical digital design process, verifying the logical correctness of a digital design and debugging the design (if necessary) are important steps of the design process performed prior to developing a circuit layout. Although it is certainly possible to test a digital design by actually building the digital design, digital designs, particularly those implemented by integrated circuitry, are typically verified and debugged by simulating the digital design on a computer, due in part to the time and expense required for integrated circuit fabrication.
In a typical automated design process, a circuit designer enters into an electronic computer-aided design (ECAD) system a high-level description of the digital design to be simulated utilizing a hardware description language (HDL), such as VHDL, thus producing a digital representation of the various circuit blocks and their interconnections. In the digital representation, the overall circuit design is frequently divided into smaller parts, hereinafter referred to as design entities, which are individually designed, often by different designers, and then combined in a hierarchical manner to create an overall model. This hierarchical design technique is very useful in managing the enormous complexity of the overall design and facilitates error detection during simulation.
The ECAD system compiles the digital representation of the design into a simulation model having a format best suited for simulation. A simulator then exercises the simulation model to detect logical errors in the digital design.
A simulator is typically a software tool that operates on the simulation model by applying a list of input stimuli representing inputs of the digital system. The simulator generates a numerical representation of the response of the circuit to the input stimuli, which response may then either be viewed on the display screen as a list of values or further interpreted, often by a separate software program, and presented on the display screen in graphical form. The simulator may be run either on a general-purpose computer or on another piece of electronic apparatus specially designed for simulation. Simulators that run entirely in software on a general-purpose computer are referred to as “software simulators,” and simulators that run with the assistance of specially designed electronic apparatus are referred to as “hardware simulators.”
As digital designs have become increasingly complex, digital designs are commonly simulated at several levels of abstraction, for example, at functional, logical and circuit levels. At the functional level, system operation is described in terms of a sequence of transactions between registers, adders, memories and other functional units. Simulation at the functional level is utilized to verify the high-level design of digital systems. At the logical level, a digital system is described in terms of logic elements such as logic gates and flip-flops. Simulation at the logical level is utilized to verify the correctness of the logic design. At the circuit level, each logic gate is described in terms of its circuit components such as transistors, impedances, capacitances, and other such devices. Simulation at the circuit level provides detailed information about voltage levels and switching speeds.
In order to verify the results of any given simulation run, custom-developed programs written in high-level languages such as C or C++, referred to as a reference model, are written to process input stimuli (also referred to as test vectors) to produce expected results of the simulation run. The test vector is then run against the simulation execution model by the simulator. The results of the simulation run are then compared to the results predicted by the reference model to detect discrepancies, which are flagged as errors. Such a simulation check is known in the verification art as an “end-to-end” check.
In modern data processing systems, especially large server-class computer systems, the number of latches that must be loaded to configure the system for operation (or simulation) is increasing dramatically. One reason for the increase in configuration latches is that many chips are being designed to support multiple different configurations and operating modes in order to improve manufacturer profit margins and simplify system design. For example, memory controllers commonly require substantial configuration information to properly interface memory cards of different types, sizes, and operating frequencies.
A second reason for the increase in configuration latches is the ever-increasing transistor budget within processors and other integrated circuit chips. Often the additional transistors available within the next generation of chips are devoted to replicated copies of existing functional units in order to improve fault tolerance and parallelism. However, because transmission latency via intra-chip wiring is not decreasing proportionally to the increase in the operating frequency of functional logic, it is generally viewed as undesirable to centralize configuration latches for all similar functional units. Consequently, even though all instances of a replicated functional unit are frequently identically configured, each instance tends to be designed with its own copy of the configuration latches. Thus, configuring an operating parameter having only a few valid values (e.g., the ratio between the bus clock frequency and processor clock frequency) may involve setting hundreds of configuration latches in a processor chip.
Conventionally, configuration latches and their permitted ranges of values have been specified by error-prone paper documentation that is tedious to create and maintain. Compounding the difficulty in maintaining accurate configuration documentation and the effort required to set configuration latches is the fact that different constituencies within a single company (e.g., a functional simulation team, a laboratory debug team, and one or more customer firmware teams) often separately develop configuration software from the configuration documentation. As the configuration software is separately developed by each constituency, each team may introduce its own errors and employ its own terminology and naming conventions. Consequently, the configuration software developed by the different teams is not compatible and cannot easily be shared between the different teams.